The present invention relates to a method and system for avoiding hanging Packet Data Protocol (PDP) contexts in a General Packet Radio Service (GPRS) network.
In the 2G/3G packet switched technology that is enabling Mobile Internet, session management is one of the main functionalities.
The packet switched core network functions are split up in two different nodes, namely SGSN (Serving GPRS Support Nodes) and GGSN (Gateway GPRS Support nodes), which together form the GSN (GPRS Support Nodes).
Between these two entities, the GTPv1 (GPRS Tunneling Protocol version 1) protocol is used for creation and management of the user sessions requested by the end users.
The GTPv1 protocol is on top of UDP/IP (User Datagram Protocol/Internet Protocol). As UDP is a connectionless protocol, it leaves to the application to take care of the handshake that a request has been successfully delivered, i.e., a response will be sent back by the receiver of a request message to the sender of the request.
In the GTPv1 protocol, a retransmission mechanism is specified to take into account that a request message may get lost on its way to a GSN peer due to disturbance on the communication line.
The mechanism is simply a maximum number of retries and the wait time between each transmission attempt. This is called the N3-T3 timeout. In normal implementations of the GTP stack, these parameters are configurable to make it possible for the operators to adjust the SGSN as well as the GGSN for the different GPRS procedures specified within 3GPP (3rd Generation Partnership Project).
At the detection of a N3-T3 timeout, the SGSN may delete all PDP (Packet Data Protocol) contexts associated with the failed path. Consequently, it is important that the GGSN responds in time in order to avoid path failure in the SGSN. A timer is started for each received request in the GGSN, and this timer controls when to abort the procedure and respond back to the SGSN. The operator configures how long this timer should be and this is of course correlated with the N3-T3 tinier in the SGSN.
Without the timer, the GGSN would potentially end up with hanging PDP contexts, for example, if the SGSN times out on N3-T3 and rejects the context and then shortly after receives a create PDP context response from the GGSN.
A SGSN will be in contact with multiple GGSNs in its own PLMN (Public Land Mobile Network) but also with a number of GGSN peers located in other PLMNs. Thus, it is not possible to set an optimal N3 and T3 value respectively to fit all GGSNs and their surrounding networks.
A problem occurs when the GGSN part of the creation procedure of a PDP context takes longer time due to temporary congestion (e.g., waiting for a response from an external node such as RADIUS (Remote Access Dial-In Server) servers, PCRFs (Policy Control and Charging Rules Function), etc.) than what is configured for the N3-T3 timeout in the SGSN requesting the creation.
The outcome of this will be that the SGSN will detect a request timeout before the procedure is concluded in the GGSN. At the time out, the SGSN will either reject the PDP context creation or try with another, redundant GGSN. And, finally, when the GGSN completes the PDP context creation and sends a successful creation response back to the SGSN, the SGSN will simply ignore the response (this is stated in the GTP standard). This will then lead to a hanging PDP context in the GGSN.
For example, as shown in FIG. 1, a SGSN 110 with an N3-T3 timeout of 8 seconds may send a “Create PDP Context Request” message 120 to a GGSN 130. If the GGSN 130 does not respond with a “Create PDP Context Response” message 140 within the 8 seconds, the SGSN 110 will either reject the PDP context creation or send a “Create PDP Context Request” message 150 to another, redundant GGSN. If, as shown in FIG. 1, the GGSN 130 responds with the “Create PDP Context Response” message 140 after 10 seconds, for example, the SGSN 110 will ignore the response, thereby resulting in a hanging PDP context in the GGSN 130.
Furthermore, it is not possible for the SGSN 110 to send a “Delete PDP Context Request” message to the GGSN 130 when the N3-T3 timer expires, as the SGSN 110 needs the TEID (Tunnel Endpoint Identifier) allocated by the GGSN 130 for that. This information, however, is included in the “Create PDP Context Response” message 140 from the GGSN 130.
In the related art, an SGSN may behave as follows when the SGSN detects path failure (N3-T3): for Echo request timeouts, the SGSN will only generate an alarm; for Create requests, the SGSN will reject the create request or, alternatively, try another GGSN; and for Update/Delete requests, the SGSN will delete the PDP context.